Virtual PBX based on Feature Server Modules

ABSTRACT

A virtual private branch exchange is formed by a plurality of interconnected feature server modules, each having an integral feature server that is configured and operates independently of the other feature server modules. Within a virtual private branch exchange, the feature server modules may be logically arranged in a hierarchy having at least a main feature server module and one or more subordinate feature server modules. A particular feature server module may operate in multiple virtual private branch exchanges, and may have a distinct set of rules for handling calls originating in different virtual private branch exchanges.

PRIORITY

This application is a continuation of U.S. patent application Ser. No.12/816,432, filed Jun. 16, 2010, entitled Virtual PBX Based on FeatureServer Modules, which is a continuation of U.S. patent application Ser.No. 11/509,793 (now U.S. Pat. No. 7,746,848), filed Aug. 24, 2006,entitled Virtual PBX Based on Feature Server Modules, which is acontinuation-in-part of U.S. patent application Ser. No. 10/729,871 (nowU.S. Pat. No. 7,248,577), filed Dec. 5, 2003, entitled Virtual PBX Basedon SIP and Feature Servers, the entire disclosures of which areincorporated herein by reference.

U.S. patent application Ser. No. 10/729,871 claims the benefit of U.S.Provisional Patent Application No. 60/431,038, filed Dec. 5, 2002,entitled Virtual PBX Based on SIP and Feature Servers, the entiredisclosure of which is incorporated herein by reference.

U.S. patent application Ser. No. 11/509,793 claims the benefit of U.S.Provisional Patent Application No. 60/786,141, filed on Mar. 27, 2006,entitled Virtual PBX Based on Feature Server Modules the entiredisclosure of which is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to telephonic communications,and more particularly to a virtual PBX (Private Branch Exchange) basedon feature server modules in a Voice-over-IP (VoIP) system.

BACKGROUND OF THE INVENTION

A Private Branch Exchange (PBX) is a subscriber-owned telecommunicationsexchange that usually includes access to the public switched telephonenetwork (PSTN). The PBX can typically provide various advanced telephoneservices, such as call hold, call transfer, call forwarding, andconferencing, to name but a few. PBX systems are generally costly, bothfor setup/maintenance and on a per-extension basis.

A Voice-over-IP (VoIP) system is a telephonic communication system inwhich telephonic communications are carried over a communicationnetwork, such as the Internet or a private intranet, using the InternetProtocol (IP). One advantage of a VoIP system is that long distancephone charges can be substantially eliminated, since long-distance voicetraffic can be carried over the Internet essentially for free. A PBXsystem can be used in conjunction with a VoIP system, in which case thePBX handles telephonic communications within the subscriber network andany voice traffic needing to go outside of the subscriber network can becarried over the VoIP system.

Some broadband (BB) phone services utilize the Media Gateway ControlProtocol (MGCP). It is a simple solution and fits very well into thesingle home residential market with an ADSL connection, while requiringa GIP (Global Internet Protocol) address at the client. However, theMGCP-based BB-phone faces a formidable challenge with Multi-dwellingUnits (MDU), apartments/condominiums and business applications. It isdifficult to obtain accessibility from the Internet to the GIP insidethe LAN.

Another protocol that is often used for VoIP is the Session InitiatedProtocol (SIP). SIP is well-known in the Internet community, and isdescribed in the following Internet Engineering Task Force (IETF)Request For Comments (RFC) documents, all of which are herebyincorporated herein by reference in their entireties:

RFC3428, Session Initiation Protocol (SIP) Extension for InstantMessaging, B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,D. Gurle, December 2002;

RFC3420, Internet Media Type message/sipfrag, R. Sparks, November 2002;

RFC3398, Integrated Services Digital Network (ISDN) User Part (ISUP) toSession Initiation Protocol (SIP) Mapping, G. Camarillo, A. B. Roach, J.Peterson, L. Ong, November 2002;

RFC3372 (BCP0063), Session Initiation Protocol for Telephones (SIP-T):(SIP-T), A. Vemuri, J. Peterson, September 2002;

RFC3361, Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option forSession Initiation Protocol (SIP) Servers, H. Schulzrinne, August 2002;

RFC3351, User Requirements for the Session Initiation Protocol (SIP) inSupport of Deaf, Hard of Hearing and Speech-impaired Individuals, N.Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk, August 2002;

RFC3325, Private Extensions to the Session Initiation Protocol (SIP) forAsserted Identity within Trusted Networks, C. Jennings, J. Peterson, M.Watson, November 2002;

RFC3324, Short Term Requirements for Network Asserted Identity, M.Watson, November 2002;

RFC3323, A Privacy Mechanism for the Session Initiation Protocol (SIP),J. Peterson, November 2002;

RFC3312, Integration of Resource Management and Session InitiationProtocol (SIP), G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg,October 2002;

RFC3311, The Session Initiation Protocol (SIP) UPDATE Method, J.Rosenberg, October 2002;

RFC3265, Session Initiation Protocol (SIP)-Specific Event Notification,A. B. Roach, June 2002;

RFC3264, An Offer/Answer Model with Session Description Protocol (SDP),J. Rosenberg, H. Schulzrinne, June 2002;

RFC3263, Session Initiation Protocol (SIP): Locating SIP Servers, J.Rosenberg, H. Schulzrinne, June 2002;

RFC3262, Reliability of Provisional Responses in Session InitiationProtocol (SIP), J. Rosenberg, H. Schulzrinne, June 2002;

RFC3261, SIP: Session Initiation Protocol, J. Rosenberg, H. Schulzrinne,G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E.Schooler, June 2002;

RFC3087, Control of Service Context using SIP Request-URI, B. Campbell,R. Sparks, April 2001;

RFC3050, Common Gateway Interface for SIP, J. Lennox, H. Schulzrinne, J.Rosenberg, January 2001;

RFC2976, The SIP INFO Method, S. Donovan, October 2000;

RFC2848, The PINT Service Protocol: Extensions to SIP and SDP for IPAccess to Telephone Call Services, S. Petrack, L. Conroy, June 2000; and

RFC2806, URLs for Telephone Calls, A. Vaha-Sipila, April 2000.

Generally speaking, SIP uses proxy servers that reside outside of thesubscriber network (i.e., coupled to the Internet) to enable telephoniccommunications to and from telephones within the subscriber network.Specifically, the subscriber network typically includes a router thatinterfaces the subscriber network to the Internet. The router typicallyacts as a firewall to prevent unauthorized access to the subscribernetwork from the Internet. The router is configured to recognize a SIPproxy server so that traffic from the SIP proxy server is allowedthrough to the subscriber network. VoIP connections can be made to andfrom the SIP phone through the SIP proxy server.

In order for a subscriber telephone to communicate over the VoIP system,the telephone must be coupled to the router. A traditional analogtelephone can connect to the router through a VoIP modem, which includesa standard telephone connection into which the telephone is connectedand a LAN (Local Area Network) connector (e.g., Ethernet) forcommunicating with the router over a LAN, and which performs thenecessary analog-to-digital and digital-to-analog conversions (and otherfunctions, such as forming packets including digitized voice data) toenable communications over the VoIP system. VoIP phones may include thenecessary conversion logic and LAN connector for operating in the VoIPsystem. For convenience, the term “SIP phone” may be used hereinafter torefer to a VoIP phone or phone/modem combination that can communicateover the VoIP system.

One advantage of SIP is that each SIP phone is not required to have aglobal IP (GIP) address. Rather, a Distributed Host ConfigurationProtocol (DHCP) server dynamically assigns IP addresses to the SIPphones in the subscriber network, and a Network Address Translator (NAT)performs IP address translations between a GIP address associated withthe router and the IP addresses assigned to the individual SIP phones.The router can act as the DHCP server and/or the NAT.

SIP adds a little more complexity to the system, as it is able topenetrate router/NAT and firewalls. Among other things, this allows theBB-SIP-Phone to work with a PBX from the existing LAN/Internetinfrastructure in place.

An example of how a telephone connection may be established in anSIP-based VoIP system is described with reference to FIGS. 1A-1H. FIG.1A shows the various elements in the system, including SIP phones 530and 540, SIP stateful proxy servers 520 and 550, an SIP stateless proxyserver 510, and an SIP redirect server 560. In FIG. 1B, the SIP phone530 sends an invite to SIP proxy server 520, which in turn sends aninvite to SIP redirect server 560. In FIG. 1C, SIP redirect server 560indicates to SIP proxy server 520 that it has moved temporarily. In FIG.1D, SIP proxy server 530 sends an acknowledgement (ACK) to SIP redirectserver 560 and sends a second invite to SIP proxy server 510. In FIG.1E, SIP proxy server 510 sends an invite to SIP proxy server 550, whichin turn sends an invite to SIP phone 540. In FIG. 1F, SIP phone 540sends an OK to SIP proxy server 550, which in turn sends an OK to SIPproxy server 510, which in turn sends an OK to SIP proxy server 520,which in turn sends an OK to SIP phone 530. In FIG. 1G, SIP phone 530sends an ACK to SIP proxy server 520, which in turn sends an ACK to SIPproxy server 550, which in turn sends an ACK to SIP phone 540. In FIG.1H, the final in-call signaling path between SIP phone 530 and SIP phone540 goes through SIP proxy server 520 and SIP proxy server 550.

SUMMARY OF THE INVENTION

In embodiments of the present invention, a virtual private branchexchange is formed by a plurality of interconnected feature servermodules, each having an integral feature server that is configured andoperates independently of the other feature server modules. Within avirtual private branch exchange, the feature server modules may belogically arranged in a hierarchy having at least a main feature servermodule and one or more subordinate feature server modules. A particularfeature server module may operate in multiple virtual private branchexchanges, and may have a distinct set of rules for handling callsoriginating in different virtual private branch exchanges.

Thus, in accordance with one aspect of the invention there is providedan internet telephony system comprising a plurality of feature servermodules operably coupled to form at least one virtual private branchexchange, wherein each feature server module includes an integralinternet telephony feature server that is configured and operatesindependently of the other feature server modules for at least one ofreceiving and forwarding internet telephone calls.

At least one virtual private branch exchange may include a plurality offeature server modules logically interconnected in a hierarchy having atleast two tiers. Telephone calls may be forwarded strictly according tothe hierarchy and/or may be forwarded among peer feature server modulesat a particular tier of the hierarchy. The hierarchy may include a mainfeature server module and at least one subordinate feature servermodule, and may additionally include at least one intermediate featureserver module operating between the main feature server module and theat least one subordinate feature server module. The main feature servermodule may be configurable to direct telephone calls to the at least onesubordinate feature server module, and each subordinate feature servermodule may be separately configurable to handle telephone callsforwarded to it by the main feature server module.

A plurality of feature server modules may be logically divided into aplurality of virtual private branch exchanges, and at least one featureserver module may be operably coupled for operation in the plurality ofvirtual private branch exchanges. Each virtual private branch exchangemay include a main feature server module and at least one subordinatefeature server module. The main feature server modules may be configuredto forward calls to the at least one feature server module operablycoupled for operation in the plurality of virtual private branchexchanges. Alternatively, or additionally, at least one subordinatefeature server module in one virtual private branch exchange isconfigured to forward calls to a feature server module in anothervirtual private branch exchange.

At least one feature server module operably coupled for operation in theplurality of virtual private branch exchanges may include a distinct setof rules for handling calls originating from each virtual private branchexchange. The main feature server modules may forward telephone callsalong with an indication of the originating virtual private branchexchange. Each subsequent feature server module may forward thetelephone call along with the indication.

In accordance with another aspect of the invention there is provided aninternet telephony apparatus comprising a network interface forreceiving internet telephone calls originating from a plurality ofvirtual private branch exchanges; a memory for storing rules forhandling the internet telephone calls, the memory including storage fora distinct set of rules for each virtual private branch exchange; and afeature server operably coupled to the network interface and the memoryfor handling each internet telephone call according to the set of rulesassociated with the originating virtual private branch exchange.

In such an apparatus, the telephone calls may be received along with anindication of the originating virtual private branch exchange, and thefeature server may retrieve the set of rules associated with theoriginating virtual private branch exchange from the memory based on theindication. The feature server may include a web interface through whichthe sets of rules can be configured. The apparatus may include atelephone interface into which a standard analog telephone can beconnected, and may also include at least one of a microphone and aspeaker.

In accordance with another aspect of the invention there is provided amethod for handling internet telephone calls originating from aplurality of virtual private branch exchanges. The method involvesmaintaining a plurality of rule sets, each rule set associated with adifferent virtual private branch exchange; receiving an internettelephone call; determining an originating virtual private branchexchange for the telephone call; and processing the telephone callaccording to the rule set associated with the originating virtualprivate branch exchange.

In such a method, the telephone call may be received along with anindication of the originating virtual private branch exchange, and theoriginating virtual private branch exchange may be determined by theindication.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings:

FIGS. 1A-1H provide an example of how a telephone connection may beestablished in an SIP-based VoIP system as known in the art;

FIG. 2 shows an exemplary VoIP modem in accordance with an embodiment ofthe present invention;

FIG. 3 shows an exemplary central line setup screen in accordance withan embodiment of the present invention;

FIG. 4 shows an exemplary direct line setup screen and an exemplarytrust setup screen in accordance with an embodiment of the presentinvention;

FIG. 5 shows an exemplary default setup screen in accordance with anembodiment of the present invention;

FIG. 6 shows a corporate telephone system incorporating both PBX andVoIP technologies in accordance with an embodiment of the presentinvention;

FIG. 7 shows a hierarchical telephone system in accordance with anembodiment of the present invention;

FIG. 8 shows a conceptual view of a feature server module in accordancewith an exemplary embodiment of the present invention;

FIG. 9 is a block diagram representing an exemplary “pure” form of VPBXwithout interconnections to PBXs or the PSTN, in accordance with anexemplary embodiment of the present invention;

FIG. 10 is a block diagram representing a “hybrid” system in which a PBXis subordinate to a VPBX, in accordance with an exemplary embodiment ofthe present invention;

FIG. 11 is a block diagram representing a “hybrid” system in which aVPBX is subordinate to a PBX, in accordance with an exemplary embodimentof the present invention;

FIG. 12 is a block diagram representing a “hybrid” system in which aVPBX interoperates with “plain old telephone” (POT) devices, inaccordance with an exemplary embodiment of the present invention;

FIG. 13 is a block diagram showing a representation of a directpeer-to-peer call transfer between personal feature server modules, inaccordance with an exemplary embodiment of the present invention;

FIG. 14 is a block diagram showing a representation of an indirectpeer-to-peer call transfer between personal feature server modules, inaccordance with an exemplary embodiment of the present invention;

FIG. 15 is a block diagram showing a representation of a call transferto an external telephone, in accordance with an exemplary embodiment ofthe present invention;

FIG. 16 is a block diagram showing a representation of a peer-to-peercall transfer between department feature server modules, in accordancewith an exemplary embodiment of the present invention;

FIG. 17 is a block diagram showing a first multiple VPBX system, inaccordance with an exemplary embodiment of the present invention;

FIG. 18 is a block diagram showing a second multiple VPBX system, inaccordance with an exemplary embodiment of the present invention;

FIG. 19 is a schematic block diagram showing an exemplary feature servermodule that supports multiple sets of rules, in accordance with anexemplary embodiment of the present invention;

FIG. 20 is a logic flow diagram for handling a call, in accordance withan exemplary embodiment of the present invention;

FIG. 21 is a logic flow diagram for handling telephone calls by a mainfeature server module of a VPBX, in accordance with an exemplaryembodiment of the present invention;

FIG. 22 is a logic flow diagram for handling telephone calls by afeature server module, in accordance with an exemplary embodiment of thepresent invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

In embodiments of the present invention, a plurality of feature servermodules interoperate to provide advanced telephone services in a VoIPsystem. The feature server modules can provide many, if not all, PBXfunctions, as well as more advanced functions. Some exemplary featureserver functions are described below.

Each feature server typically manages telephone services for anindividual telephone number, and each feature server can operate as astand-alone element that is not necessarily limited to use with acentral PBX (e.g., IP-Centrex). Each subscriber can have a personalfeature server that can be configured and managed by the subscriber andthat operates independently of other feature servers. In this respect,the feature servers are modular in that there is no central managementof the feature servers and feature servers can be easily added andremoved from the network. A network of such modular feature serversessentially operates as a virtual PBX (VPBX), enabling each subscriberto determine how telephone calls are handled independently of the otherfeature servers in the network. The virtual PBX can thereforeessentially obsolete the PBX.

The feature server(s) can be considered part of the VoIP system in thatthey typically utilize IP to communicate. The feature server(s) canreside within the subscriber network and/or outside the subscribernetwork (e.g., in the Internet). The feature server(s) can bestand-alone servers or can be multi-functional servers (e.g., an SIPproxy server or SIP redirect server can act as a feature server).

Some exemplary telephone services that can be provided by the featureserver(s) include:

Central number and hunting assignment Call holding Call transferSimultaneous ring Interrupt Conference call

A central number service is one in which a subscriber is associated witha central telephone number, and the central telephone number in turn isassociated with one or more extension telephone numbers (e.g., homephone number, work phone number, cell phone number, alternate phonenumber, secretary or answering service phone number, etc.). When thefeature server receives a call to the central telephone number, thefeature server causes one or more of the extension telephone numbers tobe called. The subscriber may specify that multiple extension telephonenumbers be called simultaneously (sometimes referred to as “simultaneousring”). The subscriber may specify multiple extension telephone numbersto be called in a predetermined sequence (sometimes referred to as“hunting”). The subscriber may specify extension telephone numbers to becalled during certain times of the day (e.g., during business ornon-business hours) or after no response to an earlier called extensiontelephone number.

A call holding service is one in which the subscriber can cause atelephone call to be placed on hold. Where the SIP phone is atraditional analog telephone, the subscriber would typically dial apredetermined command (e.g., “*H”) on the telephone keypad. Uponreceiving the command, the feature server places the call on hold. Thesubscriber may then be permitted to dial or receive another call.

A call transfer service is one in which the subscriber can cause atelephone call to be transferred. Where the SIP phone is a traditionalanalog telephone, the subscriber would typically dial a predeterminedcommand (e.g., “*T”) followed by the number to which the call is to betransferred. Upon receiving the command, the feature server transfersthe call to the specified number.

A simultaneous ring service is one in which multiple extension telephonenumbers are rung essentially at the same time when a call is receivedfor a predetermined telephone number. An example of this was describedabove with reference to central telephone number. However, thesimultaneous ring service can be provided for any phone number. Forexample, the subscriber can provide alternate telephone numbers to becalled when a home phone number or direct business phone number iscalled.

An interrupt service is one in which an outside party is permitted tointerrupt an ongoing telephone call to a subscriber. This can be handledin a number of ways. For example, the call may be placed on hold and theoutside party patched into the subscriber so that the subscriber and theoutside party can communicate exclusively, the outside party may beconferenced in so that all three parties can communicate, or the outsideparty may be permitted to speak one-way to the subscriber (e.g.,whisper). The interrupt service can be controlled by the subscriberusing commands entered through the keypad.

A conference call service is one in which multiple parties (typicallymore than two, although two parties can also be considered to be aconference) are connected.

Other types of functions can also be provided by the feature server(s),for example, using commands entered by the subscriber using the keypad.For example, the feature server(s) can provide such functions as mute,last number redial, flash, voice mail,

FIG. 2 shows an exemplary VoIP modem 400 in accordance with anembodiment of the present invention. Among other things, the VoIP modem400 includes a telephone interface 410 into which a standard analogtelephone 450 can be connected and a network interface 420 (such as anEthernet interface) for connecting to a communication network, such as aLAN (local area network) 460. The VoIP modem 400 may also include amicrophone 430 and/or speaker 440. The microphone 430 and speaker 440can be used to provide speakerphone-type services. The VoIP modem 400includes a controller 470 implementing, among other things, a personalfeature server for managing telephone calls received over the networkinterface 420 and interacting with the analog telephone 450 connected tothe POTS interface 410.

The VoIP modem 400 has a number of advantages over a traditional PBX.One advantage of the VoIP modem 400 over a traditional PBX is that theVoIP modem 400 allows inexpensive consumer telephones to be used,whereas the PBX typically requires the use of more expensive businesstelephones that are designed for the specific PBX. Another advantage ofthe VoIP modem 400 over a traditional PBX is that the personal featureserver can be managed by the user so that changes can be made quicklyand easily, whereas the PBX is typically controlled and managed by asingle person or group (e.g., an Information Technology group of acompany) and so changes must be coordinated through that person orgroup. Yet another advantage of the VoIP modem 400 over a traditionalPBX is that the VoIP modem 400 is portable, so the user can connect themodem the network wherever it is convenient and telephone calls willreach the modem using regular IP mechanisms. Thus, for example,telephone calls from a work extension can continue to be forwarded tothe user when the user is away from the office or even after the userhas left the company, provided the company's feature server isconfigured to forward calls for that user's extension to the user'smodern. Also, the user can be easily moved from one office to anotheroffice while maintaining the same extension by simply moving the modem400, whereas the PBX must typically be reconfigured when a user movesfrom one office to another office in order for the user to keep the sameextension.

When a telephone call is received over the network interface 420, thecontroller 470 can be configured to ring the telephone 450 via thetelephone interface 410, simultaneously ring the telephone 450 via thetelephone interface 410 and one or more other phone numbers via thenetwork interface 420, or immediately forward the call to anothertelephone via the network interface 420, among other things. If thetelephone 450 is rung and is not answered within a predetermined amountof time (or number of rings), then the controller 470 can be configuredto forward the call to another telephone via the network interface 420.When forwarding a call, the controller 470 can be configured tosimultaneously ring one or more other phones via the network interface420. The controller 470 can be configured with a “chain” of telephonenumbers to forward and/or simultaneously ring. Also, when a call isreceived over the network interface 420 and analog phone 450 is alreadyin use, the controller 470 can be configured to automatically forwardthe call, generate a call waiting signal to the phone 450, interrupt thephone 450, or permit one-way communication from the new caller to thephone 450 (i.e., whisper), among other things. The controller 470 canreceive signals from the phone 450 and perform various advancedtelephone functions (e.g., “*F” or “flash” to switch between two or morecalls, “*H” to put a call on hold, “*M” to mute the phone, “*S” forspeakerphone, “*C” for conference calling, “*X” to transfer a call, “*V”to change handset volume, etc.).

In exemplary embodiments of the invention, the personal feature serverincludes a web-based interface that is configurable through the networkinterface 420. Thus, when the modem 400 is connected to the network 460,it is easy for the user to manage and configure the personal featureserver using a traditional web browser. Security mechanisms arepreferably provided by the personal feature server so that only the useror other authorized persons can access the personal feature server.

FIG. 3 shows an exemplary central line setup screen 100 in accordancewith an embodiment of the present invention. When the feature serverreceives a call to the central telephone number 102, the feature servercauses the extension phone numbers 104 to be called simultaneously,except during specified non-business hours 106, in which case thenon-business hours telephone number 108 is called. If the extensionphone numbers 104 are called and none are answered within apredetermined time 109, then an alternate number 110 is called. If anyother numbers are listed in 112, then those numbers are calledsimultaneously. If no call is answered within a predetermined time 114,then a last number 116 is called.

FIG. 4 shows an exemplary direct line setup screen and an exemplarytrust setup screen in accordance with an embodiment of the presentinvention. This is very similar to central call setup, except that thetelephone number 202 would typically be the actual number associatedwith the subscriber (e.g., home phone number or direct work number).Again, the subscriber can specify simultaneous ring and alternatenumbers as well as the amount of time to delay before forwarding to analternate number. The subscriber can also specify, for the phone number206, a number of “whisper” numbers 204 (i.e., persons who are permittedto speak to the subscriber when the subscriber is on a phone call) and anumber of “interrupt” numbers 208 (i.e., persons who are permitted tointerrupt the subscriber when the subscriber is on a phone call).

FIG. 5 shows an exemplary default setup screen in accordance with anembodiment of the present invention. Here, the subscriber can specify adefault telephone number 304 to be called in case the main number 302 isunavailable due to an Internet failure.

These set up screen shots should illustrate that a PBX is no longer anecessity. However, this type of IP phone can work with an existing PBXinstalled. Over time, this scalability will obsolete the PBX as more andmore IP phone features replace the current PBX's features until the PBXis no longer needed.

In one exemplary embodiment of the invention, VoIP modems of the typedescribed above are added into corporate telephone networks. The usergenerally connects the VoIP modem to the corporate network and sets thefeature server to work with the current system. Phone calls areessentially free. Rather than buying expensive phones for use with thePBX, the subscriber can purchase inexpensive analog phones (or, for thatmatter, fancy “designer” phones that look better than traditionalbusiness phones). Even if the office changes its layout, or someone istransferred to another office, the phone number would not have to bechanged. All that would need to be done is to use the VoIP modem, accessthe Web, and make any necessary changes to the screen setups (e.g., newsecretary's number). The system could easily transition exclusively toVoIP, in which case the PBX could be eliminated.

It is preferable, although not required, for the VoIP modem to bedesigned to be thin and flat, with all connectors in the back and LEDsin the front of the unit. This way, the telephone set of a customer'schoice (any normal analog telephone would do) could sit on top of itwithout taking up extra space or giving a cheap and awkward appearanceon the office desk.

In order to provide certain advanced telephone functions using analogtelephones (such as speakerphone, announce and transfer, and hands-freeanswer), certain VoIP modems in accordance with an embodiment of thepresent invention would include a built-in speaker and possibly amicrophone, as described above.

It is desirable for the feature servers to be available regardless ofwhat ISP the customer using. Therefore, the broadband (BB) phone mustwork from inside routers/NAT translators and firewalls without anexplicit global IP (GIP) address assigned for the VoIP modem.

The BB Internet Service can use any technology, including cable modemand ADSL. For larger customers, such as corporate users, fiberconnectivity to the Internet could be used.

The feature service should be available for both residential andcorporate users. Varying the available features should differentiate thetypes of service. It is scalable from residential to corporate. Forexample, residential may not require central number service.

The VoIP modem should be considered as an embodiment of the invention inand of itself—either sold stand-alone or leased.

FIG. 6 shows a corporate telephone system incorporating both PBX andVoIP technologies in accordance with an embodiment of the presentinvention. Among other things, the telephone system includes a corporatePBX 602 in communication with VoIP modems 608 and 610 over a LAN 604 andin communication with PBX phones 612 and 614 over a telephone network.The VoIP modems 608 and 610 preferably include personal feature serversthat can be managed by the corresponding user so that central managementof the user's specific telephone requirements is not needed. The VoIPmodems 604 can be physically moved from place to place, and phone callsfrom the corporate PBX 602 will be forwarded correctly without anyconfiguration changes to the corporate PBX 602.

FIG. 7 shows a hierarchical telephone system in accordance with anembodiment of the present invention. Among other things, the telephonesystem includes a corporate feature server 702, a number of departmentfeature servers 704, and, for each department feature server 704, anumber of personal VoIP modems 706 and 708. The corporate feature server702 can be managed by a corporate manager and relates to the entirecorporation. Telephone calls received at the corporate feature server702 can be forwarded to the appropriate department feature server 704according to the extension requested. The department feature servers 704can be managed at the departmental level without impacting the corporatefeature server 702. Telephone calls received at the departmental featureserver 704 can be forwarded to a personal VoIP modem according to theextension requested. Because, as discussed above in connection with FIG.2, each personal VoIP modem includes a personal feature server, thepersonal VoIP modems 706 and 708 can be managed by their respectiveusers without impacting the corporate or departmental feature servers.Telephone calls received at the personal VoIP modems 706 and 708 can beforwarded according to the rules provided by the users. Also, it can beseen that the hierarchical telephone system includes at least onefeature server at each level of the hierarchy.

As discussed, an advantage of the personal VoIP modems is that the userscan manage their own telephone environments without impacting thecorporate or department feature servers and without involving thecorporate or departmental managers. Thus, for example, if a user'ssecretary is unavailable, the user can easily reconfigure his or herpersonal feature server to forward calls to a different secretary. Ifthe user will be temporarily in a different location, then the user caneasily reconfigure his or her personal feature server to forward orsimultaneously ring to the expected location. If the user's cell phonenumber changes, the user can easily reconfigure his or her personalfeature server to forward calls to the new cell phone. If the user isexpecting a telephone call from a particular person, the user canreconfigure his or her personal feature server to interrupt when thetelephone call is received. In the past, many of these features eitherwere not available to individual users or required that changes becoordinated through a telephone system manager.

As shown in FIG. 8, the feature server modules can be viewedconceptually as including three main functional blocks, namely a set ofcore functional features 804 sandwiched between a set of call interfacesto logical upper tiers 802 and a set of call interfaces to logical lowertiers 806. Generally speaking, calls forwarded to the feature servermodule (e.g., from an upper tier) are received by the call interfaces802 and are passed to the core functional features 804 for processing. Aparticular call might terminate at the feature server module or mightneed to be forwarded to one or more other feature server modules (e.g.,at a lower tier) via the call interfaces 806, for example, if the callis not destined for the feature server module or call forwarding iswarranted according to the call handling rules enforced by the corefunctional features 804.

Feature server modules can be logically interconnected in virtuallyunlimited ways in order to achieve desired functionality. For example,in addition to configurations shown and described above with referenceto FIGS. 6 and 7, feature server modules can be interconnected withvarious levels of hierarchy, both with and without interconnections toPBXs and/or the PSTN.

FIG. 9 is a block diagram representing an exemplary “pure” form of VPBXwithout interconnections to PBXs or the PSTN, in accordance with anexemplary embodiment of the present invention. The VPBX includes a mainfeature server module 902 and a plurality of subordinate feature servermodules 904-926. In this VPBX, all calls are received through the mainfeature server module 902 and then are forwarded from module to moduleas needed, in accordance with the core functional features processing ateach successive module.

FIG. 10 is a block diagram representing a “hybrid” system in which a PBXis subordinate to a VPBX, in accordance with an exemplary embodiment ofthe present invention. The VPBX includes main feature server module1002, a plurality of subordinate feature server modules 1004-1016,including a subordinate feature server module 1016 that acts as a bridgeto a PBX 1020 that is coupled to the VPBX through PSTN 1018. For eachcall received through the main feature server module 1002, the mainfeature server module 1002 determines whether the call is related to theVPBX or the PBX 1020. Calls related to the VPBX are forwarded frommodule to module as needed, in accordance with the core functionalfeatures processing at each successive module. Calls related to the PBX1020 are forwarded to the bridge module 1016, which forwards the call tothe PBX 1020 via the PSTN 1018. It should be noted that bridgefunctionality could be integrated into the main module 1002.

FIG. 11 is a block diagram representing a “hybrid” system in which aVPBX is subordinate to a PBX, in accordance with an exemplary embodimentof the present invention. The VPBX includes a main feature server module1102 and a plurality of subordinate feature server modules 1104-1126. Inthis VPBX, all calls are received at the PBX 1128, which forwardsappropriate calls to the main feature server module 1103 via PSTN 1130.The calls are then forwarded from module to module as needed, inaccordance with the core functional features processing at eachsuccessive module.

FIG. 12 is a block diagram representing a “hybrid” system in which aVPBX interoperates with “plain old telephone” (POT) devices, inaccordance with an exemplary embodiment of the present invention. TheVPBX includes a main feature server module 1202 and a plurality ofsubordinate feature server modules 1204-1226. In this VPBX, all callsare received through the main feature server module 1202 and then areforwarded from module to module as needed, in accordance with the corefunctional features processing at each successive module. Calls canultimately be forwarded to POT devices 1230 and 1234 over the PSTN 1228.The POT devices 1230 and 1234 represent the lowest tier of the system.

While the exemplary systems described above represent the VPBX as atop-to-bottom hierarchy of feature server modules, in practice, the VPBXtypically does not operate as a strict top-to-bottom hierarchy. Forexample, calls may be forwarded between peer modules at any tier of thehierarchy or may be forwarded from a lower tier module to a higher tiermodule.

FIG. 13 is a block diagram showing a representation of a directpeer-to-peer call transfer between personal feature server modules, inaccordance with an exemplary embodiment of the present invention. TheVPBX includes a main feature server module 1302, two department featureserver modules 1304 and 1310 serviced by the main feature server module1302, and personal feature server modules 1306, 1308, 1312, and 1314serviced by the department feature server modules 1304 and 1310. A callintended for personal feature server module 1306 is forwarded by themain feature server module 1302 to the department feature server module1304 and by the department feature server module 1304 to the personalfeature server module 1306. The personal feature server module 1306processes the call according to a predetermined set of rules, which may,for example, cause the call to be forwarded to personal feature server1308 (e.g., a backup or secretary) under certain conditions (e.g., thetelephone being serviced by personal feature server module 1306 is busyor goes unanswered for a predetermined number of rings).

FIG. 14 is a block diagram showing a representation of an indirectpeer-to-peer call transfer between personal feature server modules, inaccordance with an exemplary embodiment of the present invention. TheVPBX includes a main feature server module 1402, two department featureserver modules 1404 and 1410 serviced by the main feature server module1302, and personal feature server modules 1406, 1408, 1412, and 1414serviced by the department feature server modules 1404 and 1410. A callintended for personal feature server module 1406 is forwarded by themain feature server module 1402 to the department feature server module1404 and by the department feature server module 1404 to the personalfeature server module 1406. The personal feature server module 1406processes the call according to a predetermined set of rules, which may,for example, cause the call to be forwarded back to department featureserver module 1404 and on to personal feature server 1408 (e.g., abackup or secretary) under certain conditions (e.g., the telephone beingserviced by personal feature server module 1406 is busy or goesunanswered for a predetermined number of rings).

FIG. 15 is a block diagram showing a representation of a call transferto an external telephone, in accordance with an exemplary embodiment ofthe present invention. The VPBX includes a main feature server module1502, two department feature server modules 1504 and 1510 serviced bythe main feature server module 1502, and personal feature server modules1506, 1508, 1512, and 1514 serviced by the department feature servermodules 1504 and 1510. A call intended for personal feature servermodule 1506 is forwarded by the main feature server module 1502 to thedepartment feature server module 1504 and by the department featureserver module 1504 to the personal feature server module 1506. Thepersonal feature server module 1506 processes the call according to apredetermined set of rules, which may, for example, cause the call to beforwarded to an external telephone 1518 (e.g., a home phone or cellphone) via PSTN 1516 under certain conditions (e.g., the telephone beingserviced by personal feature server module 1506 is busy or goesunanswered for a predetermined number of rings).

FIG. 16 is a block diagram showing a representation of a peer-to-peercall transfer between department feature server modules, in accordancewith an exemplary embodiment of the present invention. The VPBX includesa main feature server module 1602, two department feature server modules1604 and 1610 serviced by the main feature server module 1602, andpersonal feature server modules 1606, 1608, 1612, and 1614 serviced bythe department feature server modules 1604 and 1610. A call intended forpersonal feature server module 1606 is forwarded by the main featureserver module 1602 to the department feature server module 1604. Thedepartment feature server module 1604 processes the call according to apredetermined set of rules, which may, for example, cause the call to beforwarded to department feature server 1610 and on to personal featureserver 1614 (e.g., a department receptionist) under certain conditions(e.g., the personal feature server 1606 is unreachable).

The VPBX paradigm can be expanded to include multiple VPBXs thatinteroperate such that some number of feature server modules operate inmultiple VPBXs. A particular feature server module can be inherentlypart of multiple VPBXs (e.g., a person employed by Company X who is alsoa member of Association Y may operate a feature server module that isserviced by both Company X's VPBX and Association Y's VPBX), or thefeature server module can be inherently part of one VPBX but receivecalls forwarded from another VPBX (e.g., a person having a first featureserver module operating in Company X's VPBX and a second feature servermodule operating in Association Y's VPBX may configure the secondfeature server module to forward calls to the first feature servermodule).

FIG. 17 is a block diagram showing a first multiple VPBX system, inaccordance with an exemplary embodiment of the present invention. Afirst VPBX (VPBX1) includes main feature server module 1702 andsubordinate feature server modules 1704-1722, while a second VPBX(VPBX2) includes main feature server module 1732 and subordinate featureserver modules 1718-1730. Thus, feature server modules 1718-1722inherently operate in both VPBXs and can handle calls received throughmain feature server module 1702 as well as calls received through mainfeature server module 1732.

FIG. 18 is a block diagram showing a second multiple VPBX system, inaccordance with an exemplary embodiment of the present invention. Afirst (corporate) VPBX includes corporate main feature server module2002 and subordinate feature server modules 2004-2012, includingdepartmental feature server module 2008 servicing personal featureserver modules for a Mr. Smith 2012 and Mr. Smith's assistant 2010. Asecond (personal) VPBX includes main feature server module 2016 andsubordinate feature server modules 2012-2014, including personal featureserver modules for Mr. Smith 2012 and Mrs. Smith 2014. In this example,calls received through the corporate main feature server module 2002and/or the main feature server module 2016 for Mr. Smith could beforwarded by Mr. Smith's personal feature server module 2012 to Mr.Smith's assistant 2010.

It should be understood that, while the exemplary embodiments shown anddescribed above with reference to FIGS. 17 and 18 show systems havingtwo VPBXs, alternative systems can include three or more VPBXs.

When operating in multiple VPBXs, a feature server module can haveseparate rules for handling calls received from different VPBXs. Forexample, a particular feature server module may include one set of rulesfor handling calls received through main feature server module 1702(e.g., for a call received through Company X's VPBX, forward the call toa company receptionist or voice mail) and a different set of rules forhandling calls received through main feature server module 1732 (e.g.,for a call received through Company Y's VPBX, forward the call to apersonal cell or home phone).

FIG. 19 is a schematic block diagram showing an exemplary feature servermodule that supports multiple sets of rules, in accordance with anexemplary embodiment of the present invention. Among other things, thefeature server module includes a network interface 1802, a featureserver 1804, and a memory 1806 in which is stored multiple sets of rules1808-1812. The feature server 1804 may include an optional web interfacefor configuring the feature server rules. The feature server module mayoptionally include a telephone interface 1814 into which a standardanalog telephone can be connected. The feature server module mayoptionally include a speaker and/or microphone 1816 for audio outputand/or input. When a call is received via the network interface 1802,the feature server 1804 retrieves the appropriate set of rules from thememory 1806 and handles the call according to the retrieved set ofrules.

FIG. 20 is a logic flow diagram for handling a call, in accordance withan exemplary embodiment of the present invention. Upon receiving a call,in block 1902, the logic determines the VPBX from which the call isreceived, in block 1904. The logic then retrieves rules for handlingcalls received from that VPBX, in block 1906. The logic then handles thecall according to the retrieved rules, in block 1908.

Thus, for example, in the system shown in FIG. 18, Mr. Smith's featureserver module 2012 could have different rules for handling callsreceived from the corporate main feature server module 2002 and theSmith family feature server module 2016. For example, calls receivedfrom the corporate main feature server module 2002 could be forwarded toMr. Smith's assistant 2010, while calls received from the Smith familyfeature server module 2016 could be forwarded to Mrs. Smith's featureserver module 2014.

In order to support the use of multiple sets of rules, the protocol usedto forward calls may include, or be revised to include, a mechanism forindicating the originating VPBX for the call. The indication wouldtypically be introduced by the main feature server module of a VPBX andbe forwarded along with the call module-by-module. Each feature servermodule could use the indication to perform VPBX-specific handling of thecall.

Thus, for example, in the system shown in FIG. 18, the main featureserver modules 2002 and 2016 could forward calls for Mr. Smith alongwith an indication as to the original VPBX for the call. Mr. Smith'spersonal feature server module 2012 could use the indication receivedalong with a call to identify the original VPBX for the call and applythe appropriate rules to the call.

FIG. 21 is a logic flow diagram for handling telephone calls by a mainfeature server module of a VPBX, in accordance with an exemplaryembodiment of the present invention. Upon receiving a telephone callfrom outside of the VPBX, in block 2102, the main feature server moduledetermines whether the telephone call was received along with a VPBXindication associated with another VPBX, in block 2104. If the telephonecall was received along with a VPBX indication associated with anotherVPBX (YES in block 2104), then the main feature server module forwardsthe telephone call along with the existing VPBX indication, in block2106. If, however, the telephone call was not received along with a VPBXindication associated with another VPBX (NO in block 2104), then themain feature server module forwards the telephone call along with a VPBXindication associated with its VPBX, in block 2108.

FIG. 22 is a logic flow diagram for handling telephone calls by afeature server module, in accordance with an exemplary embodiment of thepresent invention. Upon receiving a telephone call including a VPBXindication, in block 2202, the feature server module processes thetelephone call, which may optionally include application ofVPBX-specific rules selected according to the VPBX indication, in block2204. As part of processing the telephone call, the feature servermodule determines whether the telephone call needs to be forwarded, inblock 2206, and, if so (YES in block 2206), the feature server moduleforwards the telephone call along with the VPBX indication, in block2208.

In essence, then, a plurality of feature server modules can beinterconnected in virtually unlimited ways to form one or more VPBXs.Calls can be forwarded in multiple dimensions, including verticallywithin a VPBX (e.g., from higher-to-lower or lower-to-higher tiers),horizontally within a VPBX (e.g., peer-to-peer within a particulartier), and across multiple VPBXs. Calls can be handled according to asingle set of rules or multiple sets of rules. Calls can be forwardedalong with an indication as to the original VPBX for the call in orderto facilitate VPBX-specific call handling.

The use of feature server modules to form a VPBX facilitates managementof the VPBX. Telephone extensions can be easily added to the VPBX andremoved from the VPBX by merely reconfiguring one or more feature servermodules as appropriate. For example, a new telephone extension can beadded by simply installing a feature server module to the network andreconfiguring one or more of the existing VPBX feature server modules toforward calls to the added feature server modules. Similarly, atelephone extension can be removed by simply reconfiguring one or moreother feature server modules to stop forwarding calls to that featureserver module (even if that feature server module remains connected tothe network). Also, feature server modules can be moved within the VPBX(e.g., from one office or room to another) with little or noreconfiguration required, as the underlying internet telephony protocolstypically identify and locate devices on the network automatically.

It should be noted that, while exemplary embodiments are described abovewith reference to the Session Initiated Protocol (SIP), the presentinvention is in no way limited to SIP or to any particular protocol.Other internet telephony protocols (including existing and laterdeveloped peer-to-peer (P2P) protocols) could be employed in variousalternative embodiments of the present invention.

It should also be noted that terms such as “router” and “server” areused herein to describe various communication devices that may be usedin a communication system, and should not be construed to limit thepresent invention to any particular communication device type. Thus, acommunication device may include, without limitation, a bridge, router,bridge-router (brouter), switch, node, server, computer, or othercommunication device.

It should also be noted that the term “packet” is used herein todescribe a communication message that may be used by a communicationdevice (e.g., created, transmitted, received, stored, or processed bythe communication device) or conveyed by a communication medium, andshould not be construed to limit the present invention to any particularcommunication message type, communication message format, orcommunication protocol. Thus, a communication message may include,without limitation, a frame, packet, datagram, user datagram, cell, orother type of communication message.

The present invention may be embodied in many different forms,including, but in no way limited to, computer program logic for use witha processor (e.g., a microprocessor, microcontroller, digital signalprocessor, or general purpose computer), programmable logic for use witha programmable logic device (e.g., a Field Programmable Gate Array(FPGA) or other PLD), discrete components, integrated circuitry (e.g.,an Application Specific Integrated Circuit (ASIC)), or any other meansincluding any combination thereof. In a typical embodiment of thepresent invention, predominantly all of the feature server logic isimplemented as a set of computer program instructions that is convertedinto a computer executable form, stored as such in a computer readablemedium, and executed by a microprocessor within the feature servermodule under the control of an operating system.

Computer program logic implementing all or part of the functionalitypreviously described herein may be embodied in various forms, including,but in no way limited to, a source code form, a computer executableform, and various intermediate forms (e.g., forms generated by anassembler, compiler, linker, or locator). Source code may include aseries of computer program instructions implemented in any of variousprogramming languages (e.g., an object code, an assembly language, or ahigh-level language such as Fortran, C, C++, JAVA, or HTML) for use withvarious operating systems or operating environments. The source code maydefine and use various data structures and communication messages. Thesource code may be in a computer executable form (e.g., via aninterpreter), or the source code may be converted (e.g., via atranslator, assembler, or compiler) into a computer executable form.

The computer program may be fixed in any form (e.g., source code form,computer executable form, or an intermediate form) either permanently ortransitorily in a tangible storage medium, such as a semiconductormemory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-ProgrammableRAM), a magnetic memory device (e.g., a diskette or fixed disk), anoptical memory device (e.g., a CD-ROM), a PC card (e.g., PCMCIA card),or other memory device. The computer program may be fixed in any form ina signal that is transmittable to a computer using any of variouscommunication technologies, including, but in no way limited to, analogtechnologies, digital technologies, optical technologies, wirelesstechnologies (e.g., Bluetooth), networking technologies, andinternetworking technologies. The computer program may be distributed inany form as a removable storage medium with accompanying printed orelectronic documentation (e.g., shrink wrapped software), preloaded witha computer system (e.g., on system ROM or fixed disk), or distributedfrom a server or electronic bulletin board over the communication system(e.g., the Internet or World Wide Web).

Hardware logic (including programmable logic for use with a programmablelogic device) implementing all or part of the functionality previouslydescribed herein may be designed using traditional manual methods, ormay be designed, captured, simulated, or documented electronically usingvarious tools, such as Computer Aided Design (CAD), a hardwaredescription language (e.g., VHDL or AHDL), or a PLD programming language(e.g., PALASM, ABEL, or CUPL).

Programmable logic may be fixed either permanently or transitorily in atangible storage medium, such as a semiconductor memory device (e.g., aRAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memorydevice (e.g., a diskette or fixed disk), an optical memory device (e.g.,a CD-ROM), or other memory device. The programmable logic may be fixedin a signal that is transmittable to a computer using any of variouscommunication technologies, including, but in no way limited to, analogtechnologies, digital technologies, optical technologies, wirelesstechnologies (e.g., Bluetooth), networking technologies, andinternetworking technologies. The programmable logic may be distributedas a removable storage medium with accompanying printed or electronicdocumentation (e.g., shrink wrapped software), preloaded with a computersystem (e.g., on system ROM or fixed disk), or distributed from a serveror electronic bulletin board over the communication system (e.g., theInternet or World Wide Web).

The present invention may be embodied in other specific forms withoutdeparting from the true scope of the invention. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive.

1. A peered Internet telephone system comprising: a first Internettelephony feature server at a first location; and a second Internettelephony feature server at a second location peered with the firstInternet telephony feature server to form a virtual private branchexchange, wherein the first Internet telephony feature server operatesto direct Internet phone calls according to a first rule set that isdifferent than a second rule set for the second Internet telephonyfeature server.
 2. The peered Internet telephony system of claim 1,wherein the first Internet telephony feature server manages telephonyfor a first plurality of users and the second Internet telephony featureserver manages telephony for a second plurality of users.
 3. The peeredInternet telephony system of claim 2, wherein both the first Internettelephony feature server and the second Internet telephony featureserver are capable of being accessed by a first telephone number.
 4. Thepeered Internet telephony system of claim 3, wherein the first pluralityof users and the second plurality of users receive calls via the samerange of extensions accessed via the first telephone number.
 5. Thepeered Internet telephony system of claim 1, wherein the first Internettelephony feature server is coupled with at least one third Internettelephony feature server in a hierarchy having at least two tiers. 6.The peered Internet telephony system of claim 1, wherein the firstInternet telephony feature server is configured to be a primary featureserver and the second Internet telephony feature server is configured tobe a subordinate feature server.
 7. The peered Internet telephony systemof claim 1, wherein the Internet phone calls utilize Voice over Internetprotocol (VOIP).
 8. The peered Internet telephony system of claim 1,wherein the first and second Internet telephony feature servers arecapable of operating independently of each other.
 9. An Internettelephony system comprising: a first Internet telephony feature server;and a second Internet telephony feature server coupled to the firstInternet telephony feature server to form a virtual private branchexchange, wherein the first Internet telephony feature server is capableof directing Internet phone calls both independently of the secondInternet telephony feature server and with the assistance of the secondInternet telephony feature server.
 10. The Internet telephony system ofclaim 9, wherein the virtual private branch exchange includes aplurality of feature server modules logically coupled in a hierarchyhaving at least two tiers.
 11. The Internet telephony system of claim10, wherein the hierarchy includes a primary feature server module andat least one subordinate feature server module.
 12. The Internettelephony system of claim 11, wherein the primary feature server moduleis configurable to direct telephone calls to the at least onesubordinate feature server module, and wherein each subordinate featureserver module is separately configurable to manage telephone callsforwarded by the primary feature server module.
 13. The Internettelephony system of claim 9, wherein the first Internet telephonyfeature server manages telephony for a first plurality of users and thesecond Internet telephony feature server manages telephony for a secondplurality of users.
 14. The Internet telephony system of claim 13,wherein both the first Internet telephony feature server and the secondInternet telephony feature server are capable of being accessed by afirst telephone number.
 15. The Internet telephony system of claim 14,wherein the first plurality of users and the second plurality of usersreceive calls via the same range of extensions accessed via the firsttelephone number.
 16. The Internet telephony system of claim 9, whereinthe Internet phone calls utilize Voice over Internet protocol (VoIP).